home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000269_NED@sigurd.innosoft.com _Thu Oct 29 18:43:29 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <NED@sigurd.innosoft.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA20444; Thu, 29 Oct 92 18:43:29 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA14159; Thu, 29 Oct 92 18:55:30 +0100
  6. Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF #1339 ) id
  7.  <01GQIM2YW0LC91VWYH@SIGURD.INNOSOFT.COM>; Thu, 29 Oct 1992 09:53:10 PDT
  8. Date: 29 Oct 1992 09:53:10 -0700 (PDT)
  9. From: Ned Freed <NED@sigurd.innosoft.com>
  10. Subject: Re: misconceptions about MIME [long]
  11. To: masinter@parc.xerox.com
  12. Cc: nsb@thumper.bellcore.com, wais-talk@quake.think.com,
  13.         connolly@pixel.convex.com, www-talk@nxoc01.cern.ch,
  14.         ned@sigurd.innosoft.com
  15. Message-Id: <01GQIM2YWA8I91VWYH@SIGURD.INNOSOFT.COM>
  16. X-Vms-To: IN%"masinter@parc.xerox.com"
  17. X-Vms-Cc: 
  18.  IN%"nsb@thumper.bellcore.com, wais-talk@quake.think.com,connolly@pixel.convex.com,
  19.  www-talk@nxoc01.cern.ch, ned@sigurd.innosoft.com"
  20. Mime-Version: 1.0
  21. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  22. Content-Transfer-Encoding: 7BIT
  23.  
  24. > The arguments that in-band designation of document format is better
  25. > than out-of-band information may apply in the electronic mail
  26. > scenarios, where there is a single sender, multiple recipients, and
  27. > the recipient has no control over what the sender might send.
  28.  
  29. The argument is identical for most file servers, which have even less control
  30. over the specifics of what files they offer for retrieval. File servers usually
  31. rely on contributed material and only rarely have anything resembling precise
  32. control over the material they offer.
  33.  
  34. > Instead, imagine, if you would, another scenario, of a WAIS or Web or
  35. > anonymous FTP archive, which wishes to make available the latest
  36. > version of the MIME specification. Let us suppose, in addition, that
  37. > the publishing service has three different representations of the
  38. > document, one marked "MIME rich-text", one marked "postscript", and
  39. > one NetFax.  Furthermore, let us suppose (as has been proposed) that
  40. > the document types are marked by their MIME Content-type header
  41. > designation.
  42.  
  43. Nothing wrong with this.
  44.  
  45. > If I wish to retrieve the document, say to view it, I might want to
  46. > choose the available representation that is most appropriate for my
  47. > purpose. Imagine my dismay to retrieve a 50 megabyte postscript file
  48. > from an anonymous FTP archive, only to discover that it is in the
  49. > newly announced Postscript level 4 format, or to try to edit it only
  50. > to discover that it is in the (upwardly compatible but not parsable by
  51. > my client) version 44 of Rich Text. In each case, the appropriateness
  52. > of alternate sources and representations of a document would depend on
  53. > information that is currently only available in-band.
  54.  
  55. Even if this happens (I have strong doubts that it will since documents made
  56. available for public retrieval tend to converge rapidly to lowest-common
  57. denominator usage) you have failed to propose an alternative that solves this
  58. usefully.
  59.  
  60. > I believe that MIME was developed in the context of electronic mail,
  61. > but that the usage patterns in space and time of archives, database
  62. > services and the like require more careful attention (a) to
  63. > out-of-band information about format versions, so that you might know,
  64. > before you retrieve a representation, whether you have the capability
  65. > of coping with it, and (b) some restriction on those formats which
  66. > might otherwise be uncontrollable.
  67.  
  68. And I disagree. You still have failed to explain how to overcome any of my
  69. objections to this approach.
  70.  
  71. > Finally, as much as I've tried to resist, I'll characterize your
  72. > description of my response as 'repeated failure on your part to read
  73. > the words I was writing' as 'inflammatory hogwash'.
  74.  
  75. Well, you're doing it again. You have failed to explain you intend to overcome
  76. any of the obstacles I've pointed out, precisely as if you have not bothered to
  77. read any of my previous response. Since one of them is the halting problem in
  78. disguise your method of overcoming it (assuming you have one) will be the
  79. computing news of the century.
  80.  
  81. I have no intention of answering any further mail from you until you come
  82. to grips with the objections I have laid out for about the tenth time.
  83.  
  84. Finally, let me point out that I speak as one of the maintainers of one of the
  85. largest archive of TeX material available anywhere. This material has been
  86. available via MIME-compliant mail server (and of course FTP) for over six
  87. months now. This archive contains hundreds of PostScript documents as well
  88. as all sorts of other stuff. The problems you seem to think are endemic to
  89. this sort of services have yet to materialize.
  90.  
  91.                 Ned